home *** CD-ROM | disk | FTP | other *** search
/ The Arsenal Files 1 / The Arsenal Files (Arsenal Computer).ISO / bbs / tm0402.txt < prev    next >
Text File  |  1994-01-23  |  10KB  |  227 lines
  1. SEA Technical Memorandum #0402, ARC 6.02; Extended Data
  2. Last updated: April 28, 1989
  3. Copyright 1989 by System Enhancement Associates, Inc.
  4.  
  5.  
  6.  
  7.                                   ARC 6.02
  8.  
  9.                                Extended Data
  10.  
  11.  
  12. As of version 6.00, the ARC file archive format has been extended to 
  13. include additional information about the archive itself and the files 
  14. within it.  The purpose of this document is to describe those extended data 
  15. fields.  
  16.  
  17.  
  18. Extended data fields are implemented by the definition of additional header 
  19. type codes (refer to the ARC program sources, especially ARC.H, and to 
  20. TM0401).  The following ranges of header type codes have been defined: 
  21.  
  22.           0        End of archive marker
  23.      1 - 19        Standard compressed files
  24.     20 - 29        Information items
  25.     30 - 39        Control items
  26.     40 and up      Reserved for future use
  27.  
  28. Most of the values in these ranges have not been assigned, and are reserved 
  29. for future use.
  30.  
  31.  
  32.  
  33. Information Items
  34. =================
  35.  
  36. An information item consists of a "standard header" (identical to the 
  37. header for a standard compressed file), followed by one or more data 
  38. records.  The "size" field in the header is the total number of bytes of 
  39. data records which follow the header.  I.e. after reading the header a 
  40. relative seek of "size" bytes should position the file at the start of the 
  41. next header.  The "crc" field should be a calculated CRC of the data.  The 
  42. "length" field may be meaningless, and should be ignored.  The "date" and 
  43. "time" fields should be set to the date and time that the item was last 
  44. modified.
  45.  
  46. The data records in an information item will always have the same format:
  47.  
  48.     length    A two-byte count of the number of bytes in this record 
  49.               (including the length and type), stored in standard Intel 
  50.               format.  
  51.  
  52.     type      A one-byte record type code (see below).
  53.  
  54.     data      <length> bytes worth of data.  Content and format is 
  55.               dependend on which type of record this is and which type of 
  56.               information item it is in.  
  57.  
  58. Data records are not compressed, but may be encrypted.  The total length of 
  59. all data records in an information item may not exceed 2,000 bytes.
  60.  
  61.  
  62. The following types of information items are currently defined:
  63.  
  64.     20   Archive information
  65.  
  66.          This item contains information about the archive itself.  The 
  67.          "name" portion of the header should contain a null string.  The 
  68.          following record types are currently defined for this type of 
  69.          information item: 
  70.  
  71.          0    Archive description;  The data consists of a null-terminated 
  72.               ASCII text string describing the archive itself.  
  73.  
  74.          1    Creator;  The data consists of a null-terminated ASCII text 
  75.               string giving the name of the program that originally created 
  76.               this archive.  
  77.  
  78.          2    Modifier;  The data consists of a null-terminated ASCII text 
  79.               string giving the name of the program that last modified this 
  80.               archive.  
  81.  
  82.  
  83.     21   File information
  84.  
  85.          This item contains information about the file which follows this 
  86.          item in the archive.  This item is only valid if the "name" field 
  87.          in its header matches the "name" field in the file which follows.  
  88.          The following record types are currently defined for this type of 
  89.          information item: 
  90.  
  91.          0    Description;  The data consists of a null-terminated ASCII 
  92.               text string describing the file.  
  93.  
  94.          1    Long name;  The data consists of a null-terminated ASCII text 
  95.               string giving an alternate name for the file, which may be 
  96.               longer than the "eight dot three" filename allowed under MS-
  97.               DOS.  The "name" field given in the archive headers must 
  98.               still contain a valid MS-DOS filename, which must be unique 
  99.               in the archive.  
  100.  
  101.          2    Extended dates;  The data consists of extended date/time 
  102.               information about the file.  The exact format and content of 
  103.               the data has not yet been defined.  
  104.  
  105.          3    Icon;  The data consists of a bitmap icon representing the 
  106.               file.  The exact format and content of the data has not yet 
  107.               been defined.  
  108.  
  109.          4    Attributes;  The data contains information specifying what 
  110.               attributes the file should be given when it is extracted.  
  111.               The data consists of a null-terminated ASCII text string 
  112.               where each character represents one attribute.  The following 
  113.               attributes are currently defined: 
  114.  
  115.               R    Read only
  116.               W    Write only
  117.               H    Hidden
  118.               S    System
  119.               N    Network sharable
  120.  
  121.               Attribute characters are case sensitive and must be given 
  122.               exactly as shown.  Implementors should be prepared to see 
  123.               (and ignore) unknown attribute characters, and to contact us 
  124.               with any suggestions for new attribute characters.  
  125.  
  126.  
  127.     22   Operating system information
  128.  
  129.          This item consists of operating system specific information that 
  130.          would not be useful under other operating systems.  Which 
  131.          operating system it pertains to is given by a unique code in the 
  132.          "length" field.  Record types for this type of information item 
  133.          are specific to the operating system.  Contact SEA if you require 
  134.          this type of information item.  
  135.  
  136.  
  137.  
  138. Given the rigidly defined structure of information items, one may safely 
  139. assume that anything in the range of 20 to 29 is some sort of information 
  140. item and that it may be safely processed by the guidelines given here.  
  141.  
  142. Implementors should be prepared to deal with unknown information item types 
  143. and unknown record types, as we plan on being reasonably generous with 
  144. them.  Please contact us if you see a need for, or have a suggestion for, 
  145. any additional information item types or record types.
  146.  
  147.  
  148.  
  149. Control Items
  150. =============
  151.  
  152. The format of any given control item depends on which type of control item 
  153. it is.  See the notes below for specifics.  The following types of control 
  154. items are currently defined:
  155.  
  156.     30   Subdirectory
  157.  
  158.          This item marks the beginning of a subdirectory.  The header is 
  159.          identical in format to a standard header.  The fields in the 
  160.          header should be filled as follows: 
  161.  
  162.          name      The name of the subdirectory.
  163.  
  164.          size      The total number of bytes of compressed data for all 
  165.                    entries in the subdirectory, including headers and the 
  166.                    end of subdirectory mark.  I.e. after reading the header 
  167.                    a relative seek of "size" bytes should position the file 
  168.                    at the start of the first header after the subdirectory 
  169.                    and its contents.  
  170.  
  171.          date      This and the "time" field should be set to match that of 
  172.                    the newest entry within the subdirectory.  
  173.  
  174.          time      See "date".
  175.  
  176.          crc       Undefined.  Should be zero.
  177.  
  178.          length    The total uncompressed length of all of the entries 
  179.                    which make up the subdirectory.  
  180.  
  181.          A subdirectory may be logically extracted by creating the named 
  182.          subdirectory, and then making that the current directory.  
  183.  
  184.  
  185.     31   End of subdirectory
  186.  
  187.          This item marks the end of a subdirectory.  The header is 
  188.          identical in format to an end of archive marker (i.e. it is a two-
  189.          byte item).  
  190.  
  191.          An end of subdirectory may be logically extracted by changing to 
  192.          the parent directory ("chdir ..").  
  193.  
  194.  
  195. By their nature, control items are not as rigidly defined as information 
  196. items.  Implementors should not make assumptions about the format or 
  197. content of unknown control item types, and should not attempt to process 
  198. them.  For this reason we expect to be "stingy" in assigning new control 
  199. item types.  
  200.  
  201.  
  202.  
  203. Conclusion
  204. ==========
  205.  
  206. It is our intent to provide a platform whereby implementors of ARC-
  207. compatible utilities can store and retrieve information beyond the limits 
  208. normally associated with the MS-DOS operating system.  We're not knocking 
  209. MS-DOS, but people who have ported ARC to other operating systems have 
  210. often chafed at the loss of information that their operating system 
  211. provides.  We also intend to provide implementors of MS-DOS based ARC-
  212. compatible utilities and programs with increased functionality, to the 
  213. ultimate benefit of their (and our) users.
  214.  
  215. This enhancement to the standard ARC file archive format is the result of 
  216. the many suggestions we've received, both from users and from implementors.  
  217. We feel we've created a flexible means whereby almost any special needs can 
  218. be accomodated.  If we've left out anything you require, please feel free 
  219. to contact us.  We can be reached by voice between 9 AM and 5 PM Eastern 
  220. time at (201) 473-5153.  You can also leave a message for us on our 
  221. customer support bulletin board at (201) 473-1991.  This is a five-line 
  222. system that is available 24 hours a day at up to 2400 baud.  We can also be 
  223. reached by mail at: 
  224.  
  225.                     System Enhancement Associates, Inc.
  226.                        21 New Street, Wayne NJ  07470
  227.